SSO Information for Your IT Department

The information presented in this topic refers to the self service Learn Single Sign-On (SSO) feature. If you have a custom SSO built by the Oracle Learn Cloud Services team, and you are looking for assistance, please refer to any documentation they have provided.

Before you can set up Learn Single Sign-On (SSO), you will need to gather some information from your Information Technology (IT) Department or personnel. Share this topic with IT so that they can provide you with the necessary information for setting up your side of the Learn SSO. You can print this topic if necessary by clicking the print icon at the top of online help.

If you are a member of IT staff and you have been presented with this page, you will need to provide some key pieces of information so that your LearnCenter Administrator can properly set up Learn SSO. This topic has been written specifically with IT personnel in mind and provides you with an overview of the feature and related technical information.

Overview

Learn SSO enables your organization to integrate LearnCenter with a corporate Intranet or website. Once set up, your Users can sign in to your corporate intranet or website, and then access LearnCenter without the need to sign in a second time using their LearnCenter login credentials. You can set up SSO at either the root or the sub LearnCenter level. You can set up an SSO connection for the root and define a scope of LearnCenters that includes the root and all Sub-LearnCenters. You could also set up a connection that includes a sub LearnCenter and all of its child sub LearnCenters. The choice is yours, and you can set up an unlimited number of connections. Learn SSO is considered a "Self Service" feature, because your LearnCenter Administrator can easily configure it, with input from IT, without the need to pay for technical consulting. There is no additional cost to use this enhancement, and you do not need to notify Oracle if you begin using it.

Terminology

This section provides an overview of terminology used in this topic. While this terminology is new for LearnCenter, it is not new in general, and you are probably already familiar with the concepts. We have provided both definitions and URLs pointing to sites that provide deeper documentation on these subjects if you need it.

Click here to review the terminology and links to additional external information.

• SSO - Single Sign-On. Signing in once to gain access to multiple websites or systems. See http://en.wikipedia.org/wiki/Single_sign-on for a detailed description of Single Sign-On.

• SAML - Security Assertion Markup Language. An XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. If you are unfamiliar with the term SAML, you can find information here: http://en.wikipedia.org/wiki/SAML. SAML is a product of the OASIS Security Services Technical Committee. SAML dates from 2001; the most recent update of SAML is from 2005. SAML is a product of the OASIS Security Services Technical Committee as described in the following reference: http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf

• SAML Metadata - The metadata used to make SAML work. Additional reading can be found here: http://en.wikipedia.org/wiki/SAML_2.0#SAML_2.0_Metadata

• IDP - Identity Provider (IDP). Responsible for issuing identification information for all providers looking to interact / service with the system in any possible way, this is achieved via an authentication module which verifies a security token as an alternative to explicitly authenticating a User within a security realm. In perimeter authentication a User needs to be authenticated only once (single sign-on) and pass along a security token which is processed by an Identity Assertion Provider for each system it needs to access.

• SP - Service provider. An entity that provides Web Services. Examples of Service in the case of Learn is the service provider supplies the customers LearnCenter abcCompany.learn.taleo.net. A Service Provider relies on a trusted Identity Provider (IdP) or Security Token Service (STS) for authentication and authorization. In SAML, the XML-standard for exchanging data, the security domains that information is passed between are a Service Provider (SP) and an Identity Provider (IdP). SAML’s Service Provider (SP) depends on receiving assertions from a SAML authority or asserting party, a SAML Identity Provider (IdP). Other Service Provider technologies important to Identity Management include Software-as-a-Service (Saas), software offered using an Application Service Provider (ASP) model; and Cloud computing providers.
• IdM - Identity Management. Refers to an information system, or to a set of technologies that can be used for enterprise or cross-network identity management. IdM describes the management of individual identities, their authentication, authorization, roles, and privileges within or across system and enterprise boundaries with the goal of increasing security and productivity while decreasing cost, downtime, and repetitive tasks. "Identity Management" and "Access and Identity Management" (or AIM) are terms that are used interchangeably under the title of Identity management while Identity management itself falls the umbrella of IT Security. Additional reading can be found here: http://en.wikipedia.org/wiki/Identity_management
• RelayState - A parameter used to support Deep Linking. It is an opaque reference to state information maintained at the service provider. When a User attempts to access a Learn
• page by a deep link to a location other than the default home page, the Learn SSO passes to the identity provider the URL that the User is linking to through the Relay State parameter. The SAML relay state parameter is an optional configuration with most identity management systems, and is required to be implemented on the IDP for deep linking to be supported. In the relay state the URL passed from the LearnCenter (Service Provider) to the IDP (Identity provider) must be returned to the LearnCenter in the Relay State parameter in the exact same format as it has been provided. Additional reading can be found in the next bullet point.

• Deep Linking - Use of a URL to access a searchable or indexed piece of content on a website without having to first access that information from the home page. See the LearnCenter online help topic called SSO Deep Linking for more thorough details. Additional reading can be found here: http://en.wikipedia.org/wiki/Deep_linking

Deep linking is supported with end User and Supervisor information, as well as links within Communication Messages, Notices and Notifications. Deep linking to the Control Panel can be done if you are not using the Management password to control User access to the Control Panel. Oracle Learn Cloud does not officially support Deep Linking into the Control Panel at this time because the Management Password which controls user access into the Control Panel is not supported in the SAML standards. Deep Linking to the Control Panel will currently work if you are not using a Management password for Control Panel access, but be aware that if issues are encountered with an unsupported Control Panel Deep Link, Support will not be able to assist you.

SP-Initiated SAML

LearnCenter SSO supports the SAML standard, versions 1.1 and 2.0. SAML 2.0 is backward compatible and is the default setting, but you can still implement SSO with 1.1 if that suits your needs.

While SAML is available in two "flavors": SP-initiated (Service Provider Initiated) and IDP-Initiated (Identity Provider Initiated), the Learn SSO functionality supports SP-initiated implementation only.

SP-initiated SAML enables End Users to simply browse to Learn pages and log in. Behind the scenes and seamless to the Users, their information is redirected to the IdP, which authenticates the User and sends them back to LearnCenter.

Web browser Single Sign-On (SP-Initiated)

Most often, Users visit an SP site through a browser bookmark or direct link. In these scenarios, the User initiates the request (User Agent) by selecting a link or bookmark to the LearnCenter login page (SP) that would generate a SAML authentication request and send a redirect to the browser for the request to be submitted to Customer’s SSO URL (IdP). The User’s identity information is provided to Learn and the User is authenticated into the LearnCenter and directed to the default home page. This is also known as SP-Initiated.

The process for the LearnCenter SAML SSO via browser post:

1. A User attempts to reach a protected (closed) LearnCenter, which requires User authentication.
2. LearnCenter generates a SAML authentication request, and sends a redirect to the browser for the request to be submitted to Customer’s SSO URL. The SAML request is encoded (Base 64 encoding) and embedded into the URL (SAMLRequest query string parameter) for your SSO service. The optional RelayState parameter containing the encoded URL of the originally requested Learn page that the User is trying to reach may also be embedded in the SSO URL. This RelayState parameter is meant to be an opaque identifier that is passed back without any modification or inspection, and it’s only used if Deep Linking is required.
3. LearnCenter sends a redirect to the User's browser. The redirect URL includes the encoded SAML authentication request that should be submitted to your SSO service. Your service decodes the SAML request and authenticates the User.
4. The IDP parses the SAML request and extracts the URL for both the Assertion Consumer Service and the User's destination URL (RelayState). You then authenticate the User. You could authenticate Users by either asking for valid login credentials or by checking for valid session cookies. You generate a SAML response with an assertion. The response is digitally signed with your private key.
5. The IDP generates a SAML response that contains the authenticated User's username. In accordance with the SAML 2.0 specification, this response is digitally signed with your RSA private keys. The public key should be included in the X509 Certificate XML node so Learn can verify the signature. The assertion is posted to the LearnCenter the SAML Login Handler page, which is the SAML endpoint URL.
6. IDP encodes the SAML response and the RelayState parameter and returns that information to the User's browser. You provide a mechanism so that the browser can forward that information to LearnCenter. For example, you could embed the SAML response and destination URL in a form and provide a button that the User can click to submit the form to LearnCenter. You could also include an ‘onload’ JavaScript on the page that automatically submits the form to LearnCenter.
7. The Learn SAML Login Handler verifies the SAML response using your public key. If the response is successfully verified, the User will be granted access to LearnCenter.
8. The User is redirected to the destination URL, and is logged in to LearnCenter.

What is Needed From IT

Either IT or the LearnCenter Administrator will need to create the Integration Connection within the LearnCenter application for the scope of LearnCenters to be included in SSO. This is done on the Add Integration Connections page accessed from the LearnCenter's Control Panel. Most of the information required on that page is unique to your organization and can be provided by IT. Use the following table like a worksheet or checklist to gather the information necessary to complete the fields on the Add Integration Connections page.

Related Topics

Copyright © 2010-2015, Oracle and/or its affiliates. All rights reserved.